fix(builder): persist contractsDB across blocks within a checkpoint#21520
Merged
spalladino merged 5 commits intomerge-train/spartanfrom Mar 17, 2026
Merged
Conversation
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
spalladino
added
ci-no-fail-fast
PhilWindle
approved these changes
Mar 13, 2026
spalladino
requested review from
dbanks12,
fcarreiro and
sirasistant
as code owners
…checkpoint-builder-contracts-db
Brings down test time from +1000s to 2s.
AztecBot
pushed a commit
that referenced
this pull request
Mar 17, 2026
…21520) ## Motivation When building multiple blocks within a single checkpoint, the `CheckpointBuilder` was creating a new `PublicContractsDB` instance for each block. This meant that contracts deployed in an earlier block within the same checkpoint were not visible to subsequent blocks, causing calls to newly deployed contracts to fail. ## Approach Move the `PublicContractsDB` instance to be a persistent field on `CheckpointBuilder`, initialized once in the constructor and shared across all blocks in the checkpoint. Wrap block building in checkpoint/commit/revert semantics on the contracts DB so that failed blocks don't leak state. ## Changes - **validator-client**: Promote `contractsDB` from a local variable in `makeBlockBuilderDeps` to a class field on `CheckpointBuilder`. Wrap `buildBlock` in `createCheckpoint`/`commitCheckpoint`/`revertCheckpoint` calls on the contracts DB. - **validator-client (tests)**: Add tests verifying that the contracts DB checkpoint lifecycle is correctly managed across successful and failed block builds. - **end-to-end (tests)**: Add e2e test that deploys a contract and calls it in separate blocks within the same slot, validating cross-block contract visibility within a checkpoint. Fixes A-658 --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Collaborator
|
✅ Successfully backported to backport-to-v4-next-staging #21654. |
This was referenced Mar 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
When building multiple blocks within a single checkpoint, the
CheckpointBuilderwas creating a newPublicContractsDBinstance for each block. This meant that contracts deployed in an earlier block within the same checkpoint were not visible to subsequent blocks, causing calls to newly deployed contracts to fail.Approach
Move the
PublicContractsDBinstance to be a persistent field onCheckpointBuilder, initialized once in the constructor and shared across all blocks in the checkpoint. Wrap block building in checkpoint/commit/revert semantics on the contracts DB so that failed blocks don't leak state.Changes
contractsDBfrom a local variable inmakeBlockBuilderDepsto a class field onCheckpointBuilder. WrapbuildBlockincreateCheckpoint/commitCheckpoint/revertCheckpointcalls on the contracts DB.Fixes A-658